Improving Response Deliverability in DNS(SEC)

The Domain Name System provides a critical service on the Internet, where it allows host names to be translated to IP addresses. However, it does not provide any guarantees about authenticity and origin integrity of resolution data. DNSSEC attempts to solve this through the application of cryptographic signatures to DNS records. These signatures generally result in larger responses compared to plain DNS responses. Some of these larger responses experience fragmentation, which in turn might be partially blocked by some firewalls. Apparently unresolvable zones may in those cases be a consequence. Analysis of DNS traffic suggests that at least one per cent of all resolvers experience this problem with our signed zones. However, we suspect this number to be much larger. In our presentation we will elaborate on the potential extent of this problem and propose to test two solutions. We intent to test both solutions in our production environment

Tiqr: a novel take on two-factor authentication

Authentication is of paramount importance for all modern networked applications. The username/password paradigm is ubiquitous. This paradigm suffices for many applications that require a relatively low level of assurance about the identity of the end user, but it quickly breaks down when a stronger assertion of the user’s identity is required. Traditionally, this is where two- or multi-factor authentication comes in, providing a higher level of assurance. There is a multitude of two-factor authentication solutions available, but we feel that many solutions do not meet the needs of our community. They are invariably expensive, difficult to roll out in heterogeneous user groups (like student populations), often closed source and closed technology and have usability problems that make them hard to use. In this paper we will give an overview of the two-factor au- thentication landscape and address the issues of closed versus open solutions. We will introduce a novel open standards-based authentication technology that we have developed and released in open source. We will then provide a classification of two-factor authentication technologies, and we will finish with an overview of future work

Ethics and Internet Measurements

Over the past decade the Internet has changed from a helpful tool to an important part of our daily lives for most of the world’s population. Where in the past the Internet mostly served to look up and exchange information, it is now used to stay in touch with friends, perform financial transactions or exchange other kinds of sensitive information. This development impacts researchers performing Internet measurements, as the data traffic they collect is now much more likely to have some impact on users. Traditional institutions such as Institutional Review Boards (IRBs) or Ethics Committees are not always equipped to perform a thorough review or gauge the impact of Internet measurement studies. This paper examines the impact of this development for Internet measurements and analyses previous cases where Internet measurements have touched upon ethical issues. The paper proposes an early framework to help researchers identify stakeholders and how a network study may impact them. In addition to this, the paper provides advice on creating measurement practices that incorporate ethics by design, and also considers the role of third-party data suppliers in ethical measurement practices

On the Adoption of the Elliptic Curve Digital Signature Algorithm (ECDSA) in DNSSEC

The Domain Name System Security Extensions (DNSSEC) are steadily being deployed across the Internet. DNSSEC extends the DNS protocol with two vital security properties, authenticity and integrity, using digital signatures. While DNSSEC is meant to solve security issues in the DNS, it also introduces a new one: the digital signatures significantly increase DNS packet sizes, making DNSSEC an attractive vector to abuse in amplification denial-of-service attacks. By default, DNSSEC uses RSA for digital signatures. Earlier work has shown that alternative signature schemes, based on elliptic curve cryptography, can significantly reduce the impact of signatures on DNS response sizes. In this paper we study the actual adoption of ECDSA by DNSSEC operators, based on longitudinal datasets covering over 50% of the global DNS namespace over a period of 1.5 years. Adoption is still marginal, with just 2.3% of DNSSEC-signed domains in the .com TLD using ECDSA. Nevertheless, use of ECDSA is growing, with at least one large operator leading the pack. And adoption could be up to 42% higher. As we demonstrate, there are barriers to deployment that hamper adoption. Operators wishing to deploy DNSSEC using current recommendations (with ECDSA as signing algorithm) must be mindful of this when planning their deployment

The Internet of Names: A DNS Big Dataset - Actively Measuring 50% of the Entire DNS Name Space, Every Day

The Domain Name System (DNS) is part of the core infrastructure of the Internet. Tracking changes in the DNS over time provides valuable information about the evolution of the Internet’s infrastructure. Until now, only one large-scale approach to perform these kinds of measurements existed, passive DNS (pDNS). While pDNS is useful for applications like tracing security incidents, it does not provide sufficient information to reliably track DNS changes over time. We use a complementary approach based on active measurements, which provides a unique, comprehensive dataset on the evolution of DNS over time. Our high-performance infrastructure performs Internet-scale active measurements, currently querying over 50% of the DNS name space on a daily basis. Our infrastructure is designed from the ground up to enable big data analysis approaches on, e.g., a Hadoop cluster. With this novel approach we aim for a quantum leap in DNS-based measurement and analysis of the Internet

Understanding the Role of Registrars in DNSSEC Deployment

The Domain Name System (DNS) provides a scalable, flexible name resolution service. Unfortunately, its unauthenticated architecture has become the basis for many security attacks. To address this, DNS Security Extensions (DNSSEC) were introduced in 1997. DNSSEC’s deployment requires support from the top-level domain (TLD) registries and registrars, as well as participation by the organization that serves as the DNS operator. Unfortunately, DNSSEC has seen poor deployment thus far: despite being proposed nearly two decades ago, only 1% of .com, .net, and .org domains are properly signed. In this paper, we investigate the underlying reasons why DNSSEC adoption has been remarkably slow. We focus on registrars, as most TLD registries already support DNSSEC and registrars often serve as DNS operators for their customers. Our study uses large-scale, longitudinal DNS measurements to study DNSSEC adoption, coupled with experiences collected by trying to deploy DNSSEC on domains we purchased from leading domain name registrars and resellers. Overall, we find that a select few registrars are responsible for the (small) DNSSEC deployment today, and that many leading registrars do not support DNSSEC at all, or require customers to take cumbersome steps to deploy DNSSEC. Further frustrating deployment, many of the mechanisms for conveying DNSSEC information to registrars are error-prone or present security vulnerabilities. Finally, we find that using DNSSEC with third-party DNS operators such as Cloudflare requires the domain owner to take a number of steps that 40% of domain owners do not complete. Having identified several operational challenges for full DNSSEC deployment, we make recommendations to improve adoption

Tangled:A Cooperative Anycast Testbed

Anycast routing is an area of studies that has been attracting interest of several researchers in recent years. Most anycast studies conducted in the past relied on coarse measurement data, mainly due to the lack of infrastructure where it is possible to test and collect data at same time. In this paper we present Tangled, an anycast test environment where researchers can run experiments and better understand the impacts of their proposals on a global infrastructure connected to the Internet

Characterization of Anycast Adoption in the DNS Authoritative Infrastructure

Anycast has proven to be an effective mechanism to enhance resilience in the DNS ecosystem and for scaling DNS nameserver capacity, both in authoritative and the recursive resolver infrastructure. Since its adoption for root servers, anycast has mitigated the impact of failures and DDoS attacks on the DNS ecosystem. In this work, we quantify the adoption of anycast to support authoritative domain name service for top- level and second-level domains (TLDs and SLDs). Comparing two comprehensive anycast census datasets in 2017 and 2021, with DNS measurements captured over the same period, reveals that anycast adoption is increasing, driven by a few large operators. While anycast offers compelling resilience advantage, it also shifts some resilience risk to other aspects of the infrastructure. We discuss these aspects, and how the pervasive use of anycast merits a re-evaluation of how to measure DNS resilience

Roll, Roll, Roll your Root:A Comprehensive Analysis of the First Ever DNSSEC Root KSK Rollover

The DNS Security Extensions (DNSSEC) add authenticity and integrity to the naming system of the Internet. Resolvers that validate information in the DNS need to know the cryptographic public key used to sign the root zone of the DNS. Eight years after its introduction and one year after the originally scheduled date, this key was replaced by ICANN for the first time in October 2018. ICANN considered this event, called a rollover, "an overwhelming success" and during the rollover they detected "no significant outages". In this paper, we independently follow the process of the rollover starting from the events that led to its postponement in 2017 until the removal of the old key in 2019. We collected data from multiple vantage points in the DNS ecosystem for the entire duration of the rollover process. Using this data, we study key events of the rollover. These events include telemetry signals that led to the rollover being postponed, a near real-time view of the actual rollover in resolvers and a significant increase in queries to the root of the DNS once the old key was revoked. Our analysis contributes significantly to identifying the causes of challenges observed during the rollover. We show that while from an end-user perspective, the roll indeed passed without major problems, there are many opportunities for improvement and important lessons to be learned from events that occurred over the entire duration of the rollover. Based on these lessons, we propose improvements to the process for future rollovers

DNSSEC meets real world: dealing with unreachability caused by fragmentation

The Domain Name System (DNS) provides a critical service on the Internet: translating host names into IP addresses. Traditional DNS does not provide guarantees about authenticity and origin integrity. DNSSEC, an extension to DNS, improves this by using cryptographic signatures, at the expense of larger response messages. Some of these larger response messages experience fragmentation, and may, as a result of that, be blocked by firewalls. As a consequence, resolvers behind such firewalls will no longer receive complete responses from name servers, leading to certain Internet zones becoming unreachable because no translation into IP addresses can be performed.\ud Our research shows that despite ongoing efforts to educate firewall and resolver administrators, as much as 10% of all resolvers suffer from fragmentation-related connectivity issues. Given that some major Internet companies were reluctant to adopt even a technology like IPv6 if it meant that a small percentage of their users would have connectivity issues, it is clear that we cannot rely on resolver/firewall operators alone to tackle this issue.\ud The contribution of this paper is that it a) quantifies the severity of these DNSSEC deployment problems, based on extensive measurements at a major National Research and Education Network (NREN) and backed up by validation of these findings at an independent second location, b) proposes two potential solutions at the DNS authoritative name server side, and c) validates both solutions, again based on extensive measurements on the operational network of this major NREN. The paper concludes with a recommendation favoring our first solution. The first solution is relatively simple to implement and gives DNS zone operators control over this problem without having to rely on all resolver operators solving the issue